傳統開發流程解析

瀑布式到敏捷的演進

還記得 Waterfall 模型嗎？那個把軟體開發當成蓋房子的時代——需求分析→系統設計→實作→測試→部署→維護，每個階段都要完成才能進入下一階段。理論上很完美，實務上卻是災難。客戶在最後才發現「這不是我要的」，而我們已經花了六個月。

於是 Agile 誕生了，帶著「擁抱變化」的承諾。Scrum、Kanban、XP...各種方法論如雨後春筍般出現。我們開始有了：

• 兩週一次的 Sprint
• 每日站立會議
• Sprint Review 和 Retrospective
• Product Backlog 和 User Stories

看起來進步很多對吧？確實，我們能更快回應變化了。但仔細想想，這些真的解決核心問題了嗎？

經典的 Scrum Framework 運作方式

有段時間，筆者真的很崇尚敏捷開發，這張圖就是經典的 Scrum Framework 的運作方式，筆者幸運地在某團隊跑過成功的版本，但帶到下一個團隊後就直接悲劇了，因此理解到並不是一套方法就可以適用所有情況...

流程優化 vs 本質問題：

• Agile 優化了「管理流程」，但寫程式還是一樣累（流程管理的是溝通成本，開發成本不變）
• 我們更頻繁地交付了，但每次交付的痛苦並沒有減少
  • 每個 Sprint 都在趕工，技術債越積越多
  • 頻繁的交付反而增加了部署和整合的壓力
• 溝通變多了，但理解的落差依然存在（會議變多了，但問題也變多了）
• 我們依然在重複造輪子，只是現在是每兩週造一次
  • 相似的功能在不同專案中反覆實作
  • 知識和經驗難以在團隊間有效傳承
  • 每個開發者都在解決相同的問題，卻沒有累積可重用的解決方案

本質問題是什麼？是我們還在用 20 年前的工具和方法，試圖應對今天的複雜度。就像用算盤參加程式設計競賽——不管你的手指多靈活，終究有極限。

=
LeSS (Large-Scale Scrum) 框架

更可怕的是當團隊人變多的時候，這些問題會放大很多倍，LeSS 是個很好的方法，但其實實踐上還是沒有辦法解決根本問題（至少在某些條件下是這樣）

典型的開發週期剖析

讓我們誠實地檢視一個典型的 Sprint 是怎麼運作的：

Sprint Planning（第一天）：

• 上午：討論這個 Sprint 要做什麼
• 下午：估點數、分配任務
• 實際產出：一堆 Jira tickets

開發期間（第2-9天）：

• Daily Standup：「昨天做了什麼、今天要做什麼、有什麼阻礙」
• 實際開發時間：扣掉會議、被打斷、環境問題...可能只有 4-5 小時
• Code Review：來回修改，一個 PR 可能要 2-3 天才能 merge

Sprint 結束（第10天）：

• Demo：祈禱不要當場出包
• Retro：「下次我們要改進...」（但下次還是一樣）

真實的痛點：

• 需求理解的落差（PM 說的 vs 工程師理解的）
• 重複性工作（每個專案都在寫類似的 CRUD）
• 測試永遠寫不完（因為時間都被其他事情佔據）
• 部署還是戰戰兢兢（即使有 CI/CD）

喪屍 Scrum 的症狀

借用《喪屍Scrum生存指南》的概念，讓我們診斷一下你的團隊：

推薦閱讀：《喪屍Scrum生存指南》

筆者十分推薦這本書，裡面提到了非常多核心觀念，可以帶進團隊中少走些許彎路～

症狀一：機械化的儀式

• Daily Standup 變成「昨天我做了...今天我要做...」的機械報告
• Sprint Planning 是 PO 單向宣布任務
• Retrospective 永遠是那幾個改進項目，但從來沒實施

症狀二：假裝的自組織

• 等待 Scrum Master 分配任務
• 不敢挑戰不合理的需求
• 遇到問題就搓掉，而不是團隊內解決

症狀三：與客戶價值脫節

• 完成功能 ≠ 交付價值
• 燒完點數 ≠ 客戶滿意
• 通過測試 ≠ 解決問題

診斷結果：如果你的團隊有 2 個以上症狀，恭喜你，已經是「喪屍 Scrum」了。表面上在執行 Scrum 的儀式，但靈魂已經死去。

數據會說話

敏捷導入的期望與現實

根據業界觀察與多份調查報告，企業對敏捷開發往往抱有很高期待：

• 期望加速交付：大多數組織期待敏捷能顯著提升交付速度
• 期望提升產品品質：希望透過快速迭代來改善品質
• 期望提高團隊士氣：認為自組織團隊能提升工作滿意度

但實際成效往往不如預期，顯示「導入敏捷 ≠ 成功轉型」。

開發者時間分配現況（以每週 40 小時計）

根據業界調查，開發者的時間分配大致如下：

• 實際寫程式：12 小時（30%）
• 會議：10 小時（25%）
• 跨部門協調與溝通：8 小時（20%）
• 等待或被阻塞：5 小時（12.5%）
• 處理技術債與維運雜務：5 小時（12.5%）

換句話說：

「我們花在討論 要做什麼 的時間，往往與實際 在做什麼 差不多，甚至更多。」

技術債的雪球效應

• 成熟專案平均 30-50% 時間在處理技術債
• 維護成本逐年增加
• 「重構」永遠在下個 Sprint（但永遠不會來）

為什麼需要革命性改變

市場不等人

• 2020 年：App 開發週期 3 個月
• 2024 年：市場期待 1 個月
• 2025 年：2 週內沒有 MVP，你已經輸了

競爭對手在用什麼黑科技？答案可能讓你驚訝。

技術複雜度爆炸

十年前的 Full Stack：

• HTML + CSS + jQuery
• 一個後端框架（Rails/Django/Laravel）
• MySQL

現在的 Full Stack：

• 前端框架（React/Vue/Angular）+ 狀態管理 + 打包工具
• 微服務 + API Gateway + Message Queue
• 多種資料庫（SQL/NoSQL/Cache）+ 容器化 + 雲端服務

技術棧的複雜度大幅增加，但我們的開發方法進步了多少？

為什麼「更努力」不是答案

你不能通過：

• 開更多會來解決溝通問題
• 加更多人來加速開發（人月神話）
• 熬更多夜來提升產出
• 寫更多文件來傳承知識

因為這些都是在優化馬車，而不是發明汽車。

這些筆者都嘗試過，甚至雙管、三管、四管齊下，但沒有一個方法是真的能達到目的的

AI-Driven Development：真正的解方

問題的本質

過去 20 年，我們一直在優化「人與人的協作」，卻忽略了「人與機器的協作」。敏捷優化了管理流程，但沒有改變開發本質。

革命性的轉變

傳統開發流程：
人類思考 → 人類設計 → 人類編碼 → 人類測試 → 人類部署

AI-Driven Development：
人類意圖 → AI 理解 → 共同設計 → AI 生成+人類驗證 → 自動化測試 → 智慧部署

這不是小修小補，這是整個開發典範的轉移。

四大核心理念

1. 意圖驅動（Intent-Driven）

傳統：「我要寫一個 for 迴圈來處理陣列」
AI 驅動：「我要過濾出所有活躍用戶並發送通知」

專注於「要做什麼」而非「怎麼做」。

2. 知識放大（Knowledge Amplification）

• AI 記住所有的 best practices
• 即時提供領域特定的解決方案
• 一個人擁有整個社群的集體智慧

3. 持續生成（Continuous Generation）

• 程式碼、測試、文件同步產生
• 自動保持一致性和完整性
• 技術債在產生時就被預防

4. 人機協作（Human-AI Collaboration）

• 人類：創意、方向、商業邏輯
• AI：執行、優化、處理細節
• 1+1 > 2 的協同效應

實際案例對比

傳統方式（2週）：

• Day 1-2：需求討論、架構設計
• Day 3-8：寫程式碼
• Day 9-10：寫測試（通常寫不完）
• Day 11-12：Debug、修復
• Day 13-14：部署、文件

AI-Driven 方式（2天）：

• 上午：向 AI 描述需求，獲得架構建議
• 下午：AI 生成基礎程式碼，人類調整
• Day 2 上午：AI 生成測試，人類驗證
• Day 2 下午：部署上線，文件自動生成

效率提升不是 2 倍，是 7 倍。

透過傳統開發流程但交給 AI 落實與輔助，並且讓有經驗的人帶過整個流程，會讓整個開發流程加速非常多

個人開發者的黃金時代

對個人開發者來說，AI-Driven Development 意味著：

一人抵一個團隊

• 不再需要找後端、前端、DevOps
• AI 補足你不擅長的領域
• 專注在你的核心競爭力

專注於創造價值

• 不再浪費時間寫 boilerplate
• 把精力放在產品創新
• 更多時間理解用戶需求

競爭力的巨大提升

• 以前要 6 個月的專案，現在 1 個月
• 個人開發者也能做出企業級產品
• 快速驗證想法，快速迭代

立即行動的三個步驟

這不是未來，是現在。當你還在開 Sprint Planning 時，競爭對手可能已經用 AI 完成了 MVP。

今天就可以做的事：

1. 試用 AI 工具：GitHub Copilot、Cursor、Claude、ChatGPT
2. 小規模實驗：用 AI 重構一段程式碼或寫測試
3. 改變思維：從「怎麼寫」轉變為「要什麼」

下一篇預告

AWS 最近推出了企業級的 AI-Driven Development 框架，但對個人開發者來說，我們需要更靈活、更實用的方法。

下一篇我將分享：

• AWS AI-Driven Development Life Cycle
• 筆者的 AI-Driven Development 實踐框架

思考題：如果 AI 能幫你節省 70% 的開發時間，你會用這些時間做什麼？

記住，這不是要不要改變的問題，而是什麼時候改變。早期採用者將獲得最大的紅利。

準備好告別喪屍 Scrum，擁抱 AI-Driven Development 了嗎？

別等到競爭對手都用 AI 完成三個專案了，你還在開第一個 Sprint Planning。現在就開始你的 AI-Driven Development 之旅吧～